In the pull data consumption model, the OPC Write requests simply store the written data in the data variable object. You then write an independently running code that retrieves (pulls) the data from the data variable(s), and sends the data to the underlying system.
OPC Wizard stores the data written to the data variable in its WriteAttributeData Property. Your code retrieves the written data by getting the value of this property. When and how it is done is completely up to you, and depends highly on the specifics of the OPC server you are developing. In many cases, the retrieval will be based on some kind of periodic timer. In other scenarios, it may be triggered by the underlying system or connected device.
The pull data consumption model is inherently asynchronous, i.e. the actual data writing to the underlying system happens independently of the actual OPC Write call. This has several consequences, such as that the true outcome of the write operation cannot be returned to the OPC client, and also that the actual writing occurs at possibly later time, after the OPC Write request is fulfilled. The pull data consumption model can therefore be only used in applications where this behavior does not pose a problem.
Conversely, the advantage of the pull data consumption model is that OPC Writes are fulfilled very quickly, as the code that sends the data to the underlying system cannot "block" the OPC server.
The following picture illustrates how the pull data consumption model works.
For performance reasons, consider setting the PropagateWrite Property of the data variable to false. Since there is no handling of the Write Event or overriding of the OnWrite Method in the pull data consumption model, Write request propagation is unnecessary.
When using the pull data consumption model, in general, you are responsible for providing the initial contents of the WriteAttributeData Property. Make sure you have a reasonable contents even before your code first gets a chance to pull the data variable and process it. WIthout further configuration, the WriteAttributeData Property contains empty data - meaning that the status code is "Good", but there is no timestamp, and the value itself is null. This may not be what you want - especially with non-nullable types where null is not even a valid value for the data type of your variable. You always need to specify initial data that make sense for your server or application.
Many extension methods for Data Variable Configuration already initialize the WriteAttributeData Property at least to the default value for the given data type. This assures that the initial value is valid for that data type, but it still may not be the "right" value for your server. Some data variable configuration extension methods (such as the ReadWriteValue Method) allow you (and force you to) specify the initial data (or just the value) directly as an argument in the method call.